软件研发自然离不开需求，而且我常说：需求是源头，需求的质量最为关键，也就是我们经常说的，首先要做对事情，“做正确的事” 比“正确地做事” 更重要。需求这么重要，那么我们搞清楚需求自然也就很重要，但是许多研发同学（包括测试同学）都搞不清什么是需求，傻傻分不清 “业务需求、用户需求和系统需求”，一谈需求就会提 “系统的功能、性能” 等，完全忽视业务需求，正如文章 “业务需求与系统功能，你分清楚了吗？” 所描述的场景：
小艾：“新来的那位资深 QA 同学技术很不错，感觉对业务理解还是不够，想要他讲一下 XX Feature（特性）的业务，结果他一上来就打开系统，给我们演示具体的操作流程……” |
我也曾经看到过某企业的一个正式文档，如下所示，标题明明是“业务需求总体描述”，但一上来就是“主要功能模块”，丝毫没有业务需求的描述。
（错误的业务需求描述文档）
功能需求不是业务需求，甚至可以说是业务需求的解决方案（非功能特性是解决方案的约束条件），因为功能往往是研发人员定义和设计的，通过实现某项功能来满足用户需求，所设计的功能只是其中的一个方案。为了满足不同的业务需求，完全可以设计不同的功能、不同的UI（用户界面），例如：通过用户名/口令登陆系统，是一个 “登录” 功能需求，它要解决的问题是用户身份验证，我们也可以通过U盾、指纹、人脸识别等各种功能解决这个问题。你可能感觉某个功能好用、实现得不错，但把它放在一个特定的业务环境中，它可能就有问题，如缺乏安全性，不能满足业务要求。这也就是说，脱离业务环境来讨论软件系统的功能是没有意义的，所以今天的软件质量模型ISO/IEC 25010把之前单纯的 “功能” 改为“功能适应性”，功能必须适应业务环境才是有效的、有价值的。
说到这里，你大概了解什么是 “业务需求（Business Requirements）” ，那就是解决特定业务领域中的一个问题，例如：在个人纳税业务中，解决的问题主要有：所在区域（省、市）所有纳税人方便申报个税、个人收入汇总、已缴的税款统计、计算要补交的个税额度等。业务需求具体的表现为业务流程、业务规则、业务角色、业务数据、业务可管理性、业务发展等，针对业务也可以建模，也就是人们通常所说的领域建模和商业画布等，有图为证。
（业务建模示意图）
（商业画布/业务分析模板）
业务需求通常通过MRD（市场需求文档）、用业务领域的术语来描述，一般由业务人员和市场调研人员提出来。有些开创性的软件产品，意味着目前还不存在那样的市场，而是挖掘某一类群体所面临的问题（痛点）、所拥有的欲望或潜意识等，从而去解决这类问题或满足这类潜在的需求。
是不是有了这些业务需求，就可以讨论系统的功能或非功能特性了？别急，还没有到系统需求这个层次。你想一想，在敏捷中常常用于需求描述的“用户故事” 还没出现呢！那“用户故事” 是什么？是什么需求？“用户故事” 是用例（Use Case）另一种说法，其实就是用户行为分析，把它归为“用户角色需求”：作为一个特定的用户角色，想通过做什么到达什么目的。在某个特定的业务活动 或 业务流程中，不同的用户（end user）角色（roles）发挥不同的作用，其行为是不一样的，即需求也是不一样的。例如，在个人办税（申报）活动中，要区分收入超过12万和不到12万的用户，也要区分是自己申报还是代理人申报、是否为外籍人士或港澳台人员等。不同的用户，在同一个活动（如 办税）中所要处理的事务有差别，期望的结果也不一样。
把用户角色的需求，进一步扩展到干系人需求，包括系统运维、技术支持、销售、市场等相关人员的需求。今天，软件作为一种服务，这些干系人的需求更为显著，他们也可以看成是软件系统的广义用户。
我们所构建的软件系统最终是为用户所用，所以我们所构建的系统需要更好地满足最终用户不同角色的需求，即系统的功能是为了支持用户的需求，而业务需求要分解成用户角色需求，在敏捷中就是将业务需求（产品故事 Epic）分解为用户故事，而用户故事又需要具体的系统功能来实现。为了保证业务服务能正常开展，还需要软件系统具有良好的性能、兼容性、安全性和可靠性等支撑。
下面用一张图来说明三个层次的软件需求：业务需求、干系人需求和系统需求之间的关系。
如果从测试角度看，你可以写覆盖业务需求的用例（通常是end-to-end用例，即覆盖业务流程图中基本路径的E2E用例）；你也可以写覆盖用户角色需求的用例（通常采用基于场景的测试方法而设计的用例），即用户故事的验收标准（AC）、BDD GWT场景的实例化结果（相当于在AC、GWT的基础上加上具体的测试数据）。你也可以针对系统功能写功能测试用例、针对安全性做渗透测试、针对性能做负载测试，等等。所以，当你谈测试覆盖率时，一定要从某个需求层次的高度去谈。